perm filename AUG2.MSG[LET,JMC] blob
sn#114420 filedate 1974-10-27 generic text, type T, neo UTF8
∂2-AUG-74 1756 network site ISI
Date: 1 AUG 1974 1627-PDT
From: CROCKER at USC-ISI
Subject: Specification Language Workshop
To: Spec-Lang Group:
cc: Balzer, Cheatham at HARV-10, Crocker, Fikes at SRI-AI,
cc: Standish at BBN
You are cordially invited to attend a small workshop
on Specification Languages to be held at Harvard on Thursday
and Friday, September 5-6 for two full days, beginning at 9
a.m. on September 5.
The Subject
Specification languages are those in which you say
what your intention is without committing yourself to any
particular scheme for accomplishing it. We feel that this
area has been neglected and forms a natural interface
between program verifiers, natural language people, robot
problem-solvers and automatic programmers. We would like to
focus attention on the issues, on whatever work has been
done and is relevant, and on any new ideas that invitees may
wish to contribute.
Among other issues to be addressed, we would like to
explore what happens if we relax the constraints of
"translatability" so that we can write specs for which we do
not necessarily know a compilation technique. The purpose
for exploring this separation is that a lot of problem
solving and transformation has to take place before we can
put our requirements into a translatable form. Presently,
not enough of this process is computer mediated. Even if we
forget about trying to save programmer time, we still have
issues relating to correctness and documentation of very
large systems. The issues demand that the integration of
the parts of the system be checked by machine, at the very
least. This might be viewed as one step along the road to
fully automatic programming --- the essential issue being
how to relate the parts of a system to the whole.
Another set of issues that seem worth addressing are
those related to "semantic representations". In order to
get a computer to accept and process a specification
language in a form that provides adequate return in services
for the labor invested in creating the spec, is the computer
going to have to be equipped with a much deeper level of
semantic capability than it has at present? Our "expertise"
in being able to build up semantic models of interesting
domains seems to be an important and fundamental issue at
this time. How can we build systems that have general basic
knowledge about a domain and that can easily be given
specific information about some sub-domain or particular
class of tasks in the domain? How much of this sort of
capability must the processor of a specification language
have before it becomes genuinely useful? What are the
unsolved problems in semantic representation? What is the
prognosis for progress, and how much progress is needed to
support specification language processors in various domains
and at various levels of capability?
Page 2
Finally, what set of problems can we solve given
appropriate specification languages? E.g. (1) mechanical
consistency checking of specs, (2) mechanical document
maintenance and information retrieval of relevant segments,
(3) connection with semi-automated project management tools
for assigning tasks and monitoring for performance, (4)
input to program synthesizers that might choose
representations and write lower level programs, etc.
Plans for Agenda
Attendees are encouraged to contribute papers on new
ideas and key problem areas ahead of time. Those who want
to do a show-and-tell are encouraged to submit an abstract
in advance. An agenda will be set up that is responsive to
the material submitted. Sessions are likely to be held
along the lines of particular problem areas identified or to
focus on particular sets of ideas.
Bob Balzer has set up a directory at ISI by the name of
<SPECK> with a password of SLW. This directory should serve
as a repository for advance contributions. Rich Fikes will
examine the material submitted and will choose a
sub-committee to formulate the agenda in response to
material submitted in advance.
Local Arrangements
There is no charge for the workshop. Attendees are
expected to make their own arrangements for travel, etc.
Harvard can help make reservations for local lodging.
Local arrangements will be handled through Harvard by
Tom Cheatham (617-495-3989) and Tim Standish
(617-491-1850x543). The respective NetMail addresses are
Cheatham@Harv-10 and Standish@BBNA. Regular mail can be
addressed to:
T.E.Cheatham and T.A.Standish
Specification Languages Workshop
212 Aiken Computation Laboratory
Harvard University
Cambridge, Mass. 02138
RSVP to Cheatham or Standish at one of the above
addresses, please.
Sincerely yours,
Bob Balzer
Tom Cheatham
Steve Crocker
Rich Fikes
Tim Standish
-------
∂1-AUG-74 1708 network site ISI
Date: 1 AUG 1974 1702-PDT
From: CROCKER at USC-ISI
Subject: Specification Language Workshop
To: JMC at SU-AI
Specification Languages Workshop
You are cordially invited to attend a small workshop
on Specification Languages to be held at Harvard on Thursday
and Friday, September 5-6 for two full days, beginning at 9
a.m. on September 5.
The Subject
Specification languages are those in which you say
what your intention is without committing yourself to any
particular scheme for accomplishing it. We feel that this
area has been neglected and forms a natural interface
between program verifiers, natural language people, robot
problem-solvers and automatic programmers. We would like to
focus attention on the issues, on whatever work has been
done and is relevant, and on any new ideas that invitees may
wish to contribute.
Among other issues to be addressed, we would like to
explore what happens if we relax the constraints of
"translatability" so that we can write specs for which we do
not necessarily know a compilation technique. The purpose
for exploring this separation is that a lot of problem
solving and transformation has to take place before we can
put our requirements into a translatable form. Presently,
not enough of this process is computer mediated. Even if we
forget about trying to save programmer time, we still have
issues relating to correctness and documentation of very
large systems. The issues demand that the integration of
the parts of the system be checked by machine, at the very
least. This might be viewed as one step along the road to
fully automatic programming --- the essential issue being
how to relate the parts of a system to the whole.
Another set of issues that seem worth addressing are
those related to "semantic representations". In order to
get a computer to accept and process a specification
language in a form that provides adequate return in services
for the labor invested in creating the spec, is the computer
going to have to be equipped with a much deeper level of
semantic capability than it has at present? Our "expertise"
in being able to build up semantic models of interesting
domains seems to be an important and fundamental issue at
this time. How can we build systems that have general basic
knowledge about a domain and that can easily be given
specific information about some sub-domain or particular
class of tasks in the domain? How much of this sort of
capability must the processor of a specification language
have before it becomes genuinely useful? What are the
unsolved problems in semantic representation? What is the
prognosis for progress, and how much progress is needed to
support specification language processors in various domains
and at various levels of capability?
Page 2
Finally, what set of problems can we solve given
appropriate specification languages? E.g. (1) mechanical
consistency checking of specs, (2) mechanical document
maintenance and information retrieval of relevant segments,
(3) connection with semi-automated project management tools
for assigning tasks and monitoring for performance, (4)
input to program synthesizers that might choose
representations and write lower level programs, etc.
Plans for Agenda
Attendees are encouraged to contribute papers on new
ideas and key problem areas ahead of time. Those who want
to do a show-and-tell are encouraged to submit an abstract
in advance. An agenda will be set up that is responsive to
the material submitted. Sessions are likely to be held
along the lines of particular problem areas identified or to
focus on particular sets of ideas.
Bob Balzer has set up a directory at ISI by the name of
<SPECK> with a password of SLW. This directory should serve
as a repository for advance contributions. Rich Fikes will
examine the material submitted and will choose a
sub-committee to formulate the agenda in response to
material submitted in advance.
Local Arrangements
There is no charge for the workshop. Attendees are
expected to make their own arrangements for travel, etc.
Harvard can help make reservations for local lodging.
Local arrangements will be handled through Harvard by
Tom Cheatham (617-495-3989) and Tim Standish
(617-491-1850x543). The respective NetMail addresses are
Cheatham@Harv-10 and Standish@BBNA. Regular mail can be
addressed to:
T.E.Cheatham and T.A.Standish
Specification Languages Workshop
212 Aiken Computation Laboratory
Harvard University
Cambridge, Mass. 02138
RSVP to Cheatham or Standish at one of the above
addresses, please.
Sincerely yours,
Bob Balzer
Tom Cheatham
Steve Crocker
Rich Fikes
Tim Standish
-------